Secure network protocol and transit system to protect communications deliverability and attribution

ABSTRACT

A network protocol and transit system that together provide data tunneling designed for anonymous and hidden delivery. The approach protects communications deliverability and attribution for users on any device and in any location, irrespective of the underlying operating environment. The solution provides for a fully “cloaked network” comprising zero-trust nodes, an onion routing-based bi-directional protocol with modular multi-layered encryption, evasive multi-pathing that leverages randomized ephemeral virtual circuit generation, and virtual rendezvous for person-to-person communications. The approach may be implemented “as-a-service,” in a hybrid/bridged network, on-premises, or otherwise.

BACKGROUND Technical Field

This application relates generally to securing communications networks.

Brief Description of the Related Art

There are many well-known techniques and technologies that purport tosecure communications over computer networks.

For example, a virtual private network (VPN) extends a private networkacross a public network and enables users to send and receive dataacross shared or public networks as if their computing devices weredirectly connected to the private network. Applications running across aVPN may therefore benefit from the functionality, security, andmanagement of the private network. Encryption is commonly used in a VPNconnection. VPNs typically implement secure network protocols, such asInternet Protocol Security (IPsec), which authenticates and encryptsdata packets to provide secure encrypted communication between twocomputers over an Internet Protocol (IP)-based network. IPsec includesprotocols for establishing mutual authentication between agents at thebeginning of a session and negotiation of cryptographic keys to useduring the session. IPsec can protect data flows between a pair of hosts(host-to-host), between a pair of security gateways(network-to-network), or between a security gateway and a host(network-to-host).

Another point-to-point solution is end-to-end encryption (E2EE) is asystem of communication where only the communicating users can read themessages that are being transmitted over the network. This type ofsolution prevents potential eavesdroppers, including even the serviceprovider itself, from being able to access the cryptographic keys neededto decrypt the conversation.

Tor is an open-source solution for enabling anonymous communication bydirecting Internet traffic through a free, worldwide, volunteer overlaynetwork comprising relays to conceal a user's location and usage fromanyone conducting network surveillance or traffic analysis. Torimplements onion routing, a technique for anonymous communication over acomputer network. In an onion network, messages are encapsulated inlayers of encryption, analogous to layers of an onion. The encrypteddata is transmitted through a series of network nodes called onionrouters, each of which “peels” away a single layer, uncovering thedata's next destination. When the final layer is decrypted, the messagearrives at its destination. The sender remains anonymous because eachintermediary knows only the location of the immediately preceding andfollowing nodes. A conventional Tor implementation has a known set ofingress and egress points.

While the above-described approaches do provide useful security andprivacy guarantees in many operating scenarios, the over-reliance onencryption and point-to-point solutions mask various risks, namely,identity and geolocation exposure, the discoverability and disruption ofdata-in-transit, and the ability of malicious entities to exploit usersand their local access points.

There remains a need to provide solutions that protect communicationsdeliverability and attribution on any device and in any location,especially in untrusted networking environments.

BRIEF SUMMARY

This disclosure provides for a network protocol and transit system thattogether provide data tunneling designed for anonymous and hiddendelivery. The approach protects communications deliverability andattribution for users on any device and in any location, irrespective ofthe underlying operating environment. As will be seen, the approachherein provides for a fully “cloaked network” comprising zero-trustnodes, an onion routing-based bi-directional protocol with modularmulti-layered encryption, evasive multi-pathing that leveragesrandomized ephemeral virtual circuit generation, and virtual rendezvousfor person-to-person communications. The approach may be implemented“as-a-service,” in a hybrid/bridged network, on-premises, or otherwise.

The foregoing has outlined some of the more pertinent features of thesubject matter. These features should be construed to be merelyillustrative. Many other beneficial results can be attained by applyingthe disclosed subject matter in a different manner or by modifying thesubject matter as will be described.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the subject matter and theadvantages thereof, reference is now made to the following descriptionstaken in conjunction with the accompanying drawings, in which:

FIG. 1 depicts a representative mesh network of nodes according to thisdisclosure;

FIG. 2 depicts an example of how a client registers and announces itspresence on the network;

FIG. 3 depicts an example of an overall client lookup and privateexchange between two (2) users according to this disclosure;

FIG. 4 depicts how the clients of FIG. 3 announce their presenceanonymously;

FIG. 5 depicts how the clients of FIG. 3 each associate to a rendezvousnode through which their secure channel operates;

FIG. 6 depicts how a represent three (3) hop virtual circuit is built;

FIG. 7 depicts a UML sequence diagram corresponding to the operationsdepicted in FIGS. 4-5

FIG. 8 depicts a variant embodiment showing client Bob connecting to acorporate network via a gateway node according to another aspect of thisdisclosure;

FIG. 9 depicts a UML sequence diagram corresponding to the gateway-basedembodiment shown in FIG. 8; and

FIG. 10 depicts a distributed and loosely-coupled mesh networkcomprising nodes in multiple different domains.

DETAILED DESCRIPTION

The techniques herein provide for a private secure protocol (PSP) andnetworking solution that provides a real-time decentralized messaginglayer for distributed applications. The PSP nomenclature is not intendedto be limiting. As will be seen, PSP provides applications withanonymity, privacy and security features including, without limitation,end-to-end encryption, user-to-user authentication, and metadatatermination. The solution provides a way for applications and users tocommunicate with one another anonymously, and where sensitive usermetadata is disassociated in communication sessions. Examples of typesof metadata that are protected are user identities and IP addresses.Generally, privacy in PSP is achieved by disassociating the link betweensource and destination IP addresses and making it harder to characterizethe data. As will be seen, this prevents any network node fromassociating a user's IP address with the user's identification. Thisanonymity is used by default for one-to-one messaging, and sessionnegotiation and creation. In a representative embodiment, this privacyis implemented using an anonymous layer built on top of onion routing.In a network that uses onion routing, messages are encapsulated inlayers of encryption, analogous to layers of an onion.

The PSP and network solution typically is implemented as a network of“nodes” that are associated together in a mesh. As used herein,typically a “node” is a computing entity comprising software executingon computing hardware. These nodes comprise an overlay network (or a setof nested overlays); an overlay network is a computer network built ontop of another network, e.g., the publicly-routable Internet, a privatenetwork, a hybrid network, or the like. Referring now to FIG. 1 inparticular, a representative mesh (or “PSP”) network 100 of variousnodes is depicted. In a representative embodiment, PSP nodes areorganized into a loosely-connected mesh network. Typically, each of thenodes is connected to a subset of the other nodes at any point in time.Nodes are designed to maintain internode connections when required anddrop unused connections and re-establish them when required again. Aswill be described, typically some PSP nodes are publicly-accessible,e.g., via one or public network interfaces, and some PSP nodes serve asinternal nodes or are only used as interim or final hops in the system.Typically, nodes have various distinct roles, such as general available(onion) nodes 102, discovery nodes 104, authority nodes 106, and gatewaytraffic nodes 108. Although PSP nodes typically play different roles inthe PSP network, some nodes can be elected to play more than just asingle role. As also depicted in FIG. 1, the mesh network may integratewith a blockchain layer 110 as a Public Key Infrastructure (PKI) tostore, authenticate, validate both client and node cryptographicidentifiers, and to support other administration, management andoperational entities.

In general, an onion node 102 is used as an entry or interim node forcreating and extending onion routes, and to announce and manage onlinepoints of presence for clients of the system. These nodes facilitateonion routing, which as implemented herein provides a unique binary,bi-directional protocol with modular multi-layered encryption. Eachdiscovery node 104 provides a node digest for all the clients wishing tooperate on the network. Discovery nodes are used for getting listings ofother nodes. In particular, the node digest is agreed-upon via aconsensus algorithm (e.g., raft) that determines a correct state andlisting of all nodes on the network, and typically only discovery nodeshave a vote in the consensus. In a preferred embodiment, the discoverynodes implement a discovery/lookup service via the consensus algorithm,thereby allowing the listing to be retrieved by making such a requestupon any discovery node in the system.

The discovery nodes 104 communicate through the secure onion network(provided by onion nodes 102) to find peers (as will be describedbelow), as well as to store and retrieve values (e.g., a peer's“presence record” as will be described below). Each discovery node isidentified by a node identifier, which preferably is generated from anasymmetric cryptographic identity key of a host PSP node to providesecurity from attacks from adversarial nodes on the network. Thediscovery node contains a local datastore for storing key-value pairs,as well as a routing table that is used to locate peers on the network.Preferably, all nodes (regardless of their role) report their statusperiodically to all known discovery nodes they can reach. As notedabove, discovery nodes do a voting and build consensus periodically toform a new list of nodes, and this list is signed with one or morediscovery keys. This periodically-generated list of nodes typicallycontains a full list of all public nodes, node flags, node addresses(for entry nodes, if available), and geographic locations. In thissystem, nodes bootstrap the discovery using publicly-available discoveryinformation, and they preferably reseed it during the session byperforming queries to a random distinct node from a most recentdiscovery digest. From a security perspective, discovery nodes 104 thatparticipate in the discovery process are acting as privileged nodes;preferably, a final list of discovery nodes is established by electing anumber of trusted nodes, and this full list is then made availablepublicly.

As will be described below, onion nodes 102 in PSP provide the abilityfor clients (e.g., endpoints, or peers) to communicate securely andprivately by allowing onion nodes 102 to publish presence informationfor clients requesting that functionality. That presence information canthen be requested by any other client on the network, allowing the onionnodes to then form a bridge (using one or more so-called “virtual”circuits) between clients to facilitate secure and private communicationbetween parties without compromising the location of any party on thenetwork.

Referring back to FIG. 1, some of the nodes preferably are elected asauthority nodes 106, wherein an authority node acts as a bridge to a PKIlayer 110. An authority node 106 typically performs as an authorizationsource for other nodes and clients of the system. Gateway traffic nodes108 facilitate on-premises (e.g., customer) deployments where first orlast mile requirements dictate implementation directly with trusted/DMZblack side (dirty Internet) of router ports. Gateway nodes are useful inoperating environments such as classified and confidential site-to-site,or remote site applications. Additionally, a gateway node 108 is usefulas an exit node from the PSP network, e.g., to facilitateconsumer/business browsing traffic for services that may exist outsidethe closed and cloaked PSP environment. Although not depicted, othernode types may be provided. These include oracle nodes, which act asnetwork validators collecting and confirming node bandwidth utilization,commercial nodes, which act as application-specific nodes providingdynamic business logic support for applications, bridge nodes, which actas regular onion nodes but that are not listed on a publicly-availablenode digest; bridge nodes act a system entry points with respect tolocations that might otherwise be geographically-blocked.

In order for clients to be able to announce their presence informationfor other users, the system provides a distributed data storage of suchpresence information available from any discovery node. Preferably, thedistributed data storage comprises a Distributed Hash Table (DHT). Inone embodiment, DHT is an implementation of Kademlia modeled after IPFS(a distributed filesystem) with S/Kademlia modifications to mitigatevulnerabilities against known network-based attacks. In general, and aswill be seen, PSP clients depend on DHT to facilitate the ability ofonion nodes 102 to provide private and secure communication betweenparties (peers) using the PSP network. DHT is responsible for recordingand making information available in a fast, secure, stable, and scalablemanner to enable such secure communication, all without sacrificingprivacy.

To prevent unauthorized modifications of data on the DHT layer everyrecord on a table preferably is signed by the record owner and co-signedby the node originally publishing the record. The record owner typicallyis defined as the originator of the record, which can be a client, nodeor group identity. Both nodes and consuming clients only accept datathat they are able to validate, confirm the ownership of and can verifythe signature. Preferably, every record on the DHT is assigned with anexpiration time must be periodically renewed to continue to be listed.Once a record expires, it gets automatically wiped by all nodes.

Preferably, a default core set of discovery nodes is provided to aclient that uses the service, and a client may require some minimumnumber of signatures from known discovery nodes to be present (i.e., tohave its presence information recorded) on a directory listing that willthen be shared across the discovery nodes. The signatures are used sothat the listing may be trusted as a valid, and also for use in buildingroutes.

Preferably, any participating (node, privileged node or end userapplication) identity is represented by a namespace, applicationnamespace and public key identifying the client entity on a PKI store(part of layer 110). Every identity can be validated against the systemPKI store using a set of one or more authority nodes 106. This resultsin building a temporary access certificate, which allows a client tooperate on a system signing announcements and introduction requestsusing that identity.

The following section provides further details regarding clientregistration and presence announcement on the network. As noted above,preferably client applications use onion routing to hide the user IPaddress from various parts of the system. To build the route (sometimesreferred to herein as a virtual circuit), the client decides on all thenodes on the path it is going to use, and then telescopically extendsthe path from one node to another, node-by-node, preferably implementingan asymmetric encryption algorithm scheme to build a session key foreach new hop over an encrypted TLS (Transport Layer Security) pipe (fromthe client to the entrance node, and from node to node for all interimnodes). Preferably, every node on a network limits the send rate so thatthe onion routing layer itself is not used for passing real-time data.Rather, preferably it is used only for the presence/signaling layer anddirect user-to-user private messaging.

Presence is announced anonymously. In particular, for a client toestablish its presence on the system without revealing network identity,preferably the approach herein detaches the user presence node from theclient's real entrance point. To this end, the client preferablyregisters several points of contact for itself, and these points aresometimes referred to as presence nodes. In a preferred scheme, theclient discovers three (3) independent nodes on the network. The clientthen chooses which node becomes the client's entrance node, which nodebecomes the client's presence node, and then the client proceeds tobuild an onion route towards the destination. This operation is depictedin FIG. 2. In this example, client Alice 200 chooses node A as anentrance node and node C as her presence node. Initially, Alice connectsto the node A anonymously, using the handshake key from node A.Preferably, this link is then used to establish a Diffie-Hellman (D-H)key exchange using an asymmetric encryption algorithm, thereby creatinga session key K between Alice and node A. After a secure connection isestablished in this manner, Alice then requests that node A extend theconnection on her behalf, reaching node B. Alice then requests node Aextend to further reach node C, where in this example Alice reveals heridentity, preferably signing a registration message with her accesscertificate. Alice then announces herself (using the DHT storagemechanism previously described) using node C as the presence point forher across the entire network of nodes. Preferably, this announcement isco-signed by the node C and assigned some expiration time. Alice thencan renew the presence registration by sending keep-alive events overthat channel periodically. For fault tolerance, Alicen may registermultiple such presence endpoints, and clients discovering her should beable to choose which entries are most recent, and be able to contact oneor several of them. In a variant embodiment, and where full anonymity isnot required, a client is able to establish the presence on a first hop,and without necessarily building a three (3) hop route as has beendescribed. This variant, however, does not hide the relation betweenclient IP address and the client's public identity.

With reference now to FIG. 3, a high level depiction is provided of aclient lookup and private communication exchange between clients Alice300 and Bob 302. In this example, it is assumed that Bob established hispresence point at node Z and his presence is recorded in the DHT. Thefollowing describes the process Alice uses to discover and reach Bob ina secure manner. This mechanism prevents revealing to any observer (orother nodes participating in session) that these users are communicatingwith one another. To this end, Alice first chooses preferably three (3)additional nodes, in this example scenario nodes B, C and D. Alice thenuses the created circuit (sometimes referred to as a virtual circuit) toperform a “user lookup” request in an anonymous manner, receiving inreturn a list of Bob's presence points. After obtaining the list, Alicethen builds a similar route G, H and I, using I as the destination node.Once this circuit is built, Alice establishes it (node I) as arendezvous point, delivering half-sequence initialization for the newsession with Bob. After establishing the rendezvous point, Alice learnsBob's presence node Z from the DHT; Alice then extends the new route D,E towards one of Bob's presence nodes Z, thereby forming new circuit D,E and Z. Thereafter, Alice creates an introduction request containingher identity and her rendezvous point I. She then encrypts thatinformation, preferably using Bob's announcement key. Finally, Alicedelivers this message (the encrypted information) through the route soonly Bob is able to unwrap the message without revealing to node Z thatthe original sender is Alice. If Bob then accepts the request, hecreates a new circuit K, L and I, ending up at rendezvous node I. Bobthen completes a second half of the secure connection in a similarmanner, resulting in the creation of a new secure channel between Aliceand Bob that is only known to the two users involved.

The secure channel is a binary, bi-directional channel that carries thefull network payload for the communications between Alice and Bobthereafter.

Due to the anonymous nature of these communication channels, a nodeitself is unable to validate the authenticity of the incoming connectionrequest. Therefore, each communication channel has to be approved by thereceiving client application. Preferably, this is done by limiting theamount of creation requests being processed by a single node at anygiven moment of time (or over some configurable time period), andallowing the node the ability to request cancellation of any request.Such cancellation results in immediate termination of a route built fromthe other client to the presence node. Preferably, the PSP network isalso able to specify a rate limit for every communication channelcreated, thereby allowing the presence node to throttle the data volumeand to specify a hard channel limit, capping the numbers of channelscreated to the single presence of the client. In this scenario, theclient should be notified when the cap is reached so that the userthereof has the opportunity to register more presence endpoints ifneeded.

FIGS. 4-5 depict the above described example in additional detail. Inparticular, and as shown in FIG. 4, each party is depicted announcingtheir presence anonymously. For example, Alice connects to a discoverynode to obtain a list of all nodes on the network. As was described,Alice establishes a virtual circuit 402 to create a presence record andwithout revealing her source network identity. Preferably, the virtualcircuit 402 is created as a 3-hop virtual circuit to a random onion node404, and with Alice selecting each node at random. She then asks theonion node 404 to register a presence record, which record is stored inthe DHT that all onion nodes share. Bob repeats this process. Inparticular, Bob also obtains a node list via the discovery service. Bobalso establishes a virtual circuit 408 to create a presence record,e.g., at node 410. As shown, and despite unknowingly routing trafficthrough Mike, Mike cannot identify either Bob or Alice. In other words,Mike cannot coerce Alice or Bob to pass traffic through Mike's node.Mike also cannot even determine which stage in Bob's connection processhis node is participating.

FIG. 5 then depicts the two clients establishing the secure channelbetween them. In particular, Alice builds a virtual circuit 502 to a PSPnode 504 to perform a lookup of Bob's presence announcement records.Concurrently, she also builds another virtual circuit 506 to arendezvous node 508. Alice retrieves Bob's presence record, and thenestablishes another virtual circuit 510, this time to Bob's presencenode 512, to request a connection (which if accepted will be built viathe rendezvous node 508). If Bob then accepts the request, he builds avirtual circuit 514 to the rendezvous node 508. In this manner, Aliceand Bob now have a new secure channel between and known only to them. Noobserver or node (e.g., Mike) participating in the session knows Aliceand Bob are communicating. Alice builds The presence record tells Alicewhere to find Bob's presence node, at which she can then go to request aconnection (via the rendezvous node 508).

Thus, and as has been depicted, when clients (such as Alice or Bob) talkto the discovery service (the discovery nodes), a list of all the nodesin the network is typically obtained. Obtaining a full list is notrequired for presence (e.g., Alice posting a presence record) or lookups(Bob going to look it up). As the example scenario (FIGS. 4-5) makesclear, the approach herein enables the clients seeking to establish thesecure channel to generate and use multiple virtual circuits. Thesecircuits are built by clients picking random nodes, and thus the virtualcircuits can also be considered to be randomized and indeed ephemeral innature. This provides for multi-pathing that is highly resistant todiscovery even by the nodes that participate in the session itself.

FIG. 6 depicts the preferred three (3) hop virtual circuit generationand use. This is the notion of the client building a virtual circuit,preferably using three or more nodes picked at random. As depicted, itis assumed that the client (not shown) located at the source desires tosend a message 600 to a destination via the three (3) hop circuitcomprising nodes A, B and C. Although three (3) hops are shown, this isnot a limitation, as additional hops (nodes). For a typical three (3)virtual circuit as shown, however, three (3) layers of encryption areapplied to the message. Node A can only decrypt the outer layer, leavingtwo (2) layers of encryption. Node B can only decrypt the outer layer,still leaving one encrypted layer. Only node C can remove thatencryption. As a result, a zero trust arrangement is established acrossthe circuit as a whole, meaning that node B only sees node A and node C,but node B cannot access the message contents. The innermost payload iseffectively end-to-end encrypted. Zero trust nodes mitigate network-bornattacks, thereby minimizing exposure to co-opted network nodes. Asvirtual circuits built in the manner typically rely on random nodes, theapproach herein provides for evasive multi-pathing, as has beendescribed.

FIG. 7 depicts a representative UML-based sequence diagram correspondingto the technique by which the clients announce their presenceanonymously and then use DHT and virtual circuit building to connect toone other via a secure channel built through a rendezvous node.

The techniques herein are not limited to client-to-client scenarios,such as the Alice-to-Bob secure communication scenario. As noted above,a common node type may be a “gateway,” and FIG. 8 depicts anothercommunication scenario. In this example, client Bob desires to connectto a protected network, such as a corporate network accessed through aVPN 800 or the like. In this case, Bob desires to anonymously connect tothe VPN. As seen in FIG. 8, and using the techniques previouslydescribed, Bob connects to a discovery node to obtain a list of allnodes on the network. Bob then establishes a three (3) hop virtualcircuit 802 to a gateway node 804. Bob then asks the gateway node 804 toestablish a connection to the VPN 800. The gateway node 804 checks Bob'sauthorizations. If Bob is authorized to access the protected networkthrough the VPN, the gateway node 804 then establishes a VPN connection806 to the protected network. As also shown, malicious node operatorMike cannot coerce Bob to send traffic through his node. Even if trafficdoes pass through Mike, Mike cannot determine the true start or end ofthe circuit, nor the requestor involved. FIG. 9 depicts a full UMLsequence diagram for this operating scenario. As a skilled person willappreciate, the approach depicted in FIGS. 8-9 provide for a VPN-likesolution that not only protects content, but also identity. The approachin this example anonymizes and randomizes connections, providing evasiveand ephemeral multi-pathing, to prevent snoopers from even knowing thatthe user is using a VPN.

The protected network may be a corporate network or, more generally, asecure remote network.

Thus, according to the above-described technique, specialized nodes (asdescribed above) are used to facilitate the creation of the binary,bi-directional and ephemeral communication channel. No exit or relaynodes are required to be used. The PSP presence mechanism preferablyuses a DHT lookup to a known presence area (a presence record) that ishashed with an identity of the user to which the DHT entry belongs.Additionally, preferably the node that entered the record into the hashtable is also entered into the record. When the identity is looked up,the user identity is used to know where to look up the record. Thus,typically only the record of a known PKI entity can be looked up. Asalso previously described, in PSP preferably presence announcements arepublished periodically. When a client does a lookup of a userannouncement from DHT, it receives a list of records. This servesseveral purposes; it allows multiple announcements (renewal) during agiven period, and it allows messaging to be received on multiple devicesthat are looked into the same account simultaneously. And as alsopreviously described, in PSP a client uses a lookup presence request toget an announcement (a presence record), but then reaches the desiredother user via another node specified in the announcement record. Asalso noted, a user (client) typically performs a registration operationvia an authority node. The authority node returns a certificate thatallows the user to thereafter use the network; in particular, the userperforms his or her announcement. Another user wanting to connect wouldthen perform a lookup presence, obtain the announcement record, and thendo a forward presence request.

More generally, the approach herein may provide secure communicationchannels for various different types of operating scenarios including,without limitation, person-to-site (remote access), person-to-person(mobile-based), site-to-site and cross-domain, ITN and tactical edge,IoT-based, and others.

FIG. 10 depicts a generalized distributed and loosely-coupled meshnetwork that includes nodes from multiple different networks and/oroperating domains, in this example, the mesh comprises nodes located inMicrosoft® Azure® 1000, nodes located in Google® Cloud 1002, and nodeslocated in Amazon® AWS 1004. Of course, this is just a representativeembodiment, but not intended to be limiting.

More generally, there are many possible deployment options for theabove-described techniques. These include Network-As-A-Service (NaaS) (ahosted and managed service provided by a service provider),hybrid/bridged networks (e.g., wherein internal users operating on amanaged, secure network receive defense “in depth,” and withinfully-managed secure networks (e.g., on premise). Further, thetechnologies described may be implemented/integrated in various ways,e.g., a software-based solution or as a portable router device, via anSDK/API integration (e.g., for IoT, sensors, and standalone networkedhardware), as a secure messaging and voice mobile device-basedapplication (app), combinations of the above, and many others.

Typically, a “client” as used herein refers to a computing machineassociated with the named person (e.g., Alice, or Bob). It is notnecessarily required that a client be associated with a human being. Aclient may be an autonomous entity, such as an IoT endpoint or device.

It is not required that a particular virtual circuit have at least three(3) nodes.

While a node typically is associated with a single computing machine,this is not a requirement either. More than one node may be co-locatedon a particular machine.

A machine as used herein may be a physical machine or a virtual machine.

The peer-to-peer communication techniques described above may also beused to facilitate a 1-to-many communication among two or more clients.

Enabling Technologies

One or more functions of the computing platform of this disclosure maybe implemented in a cloud-based architecture. As is well-known, cloudcomputing is a model of service delivery for enabling on-demand networkaccess to a shared pool of configurable computing resources (e.g.networks, network bandwidth, servers, processing, memory, storage,applications, virtual machines, and services) that can be rapidlyprovisioned and released with minimal management effort or interactionwith a provider of the service. Available services models that may beleveraged in whole or in part include: Software as a Service (SaaS) (theprovider's applications running on cloud infrastructure); Platform as aservice (PaaS) (the customer deploys applications that may be createdusing provider tools onto the cloud infrastructure); Infrastructure as aService (IaaS) (customer provisions its own processing, storage,networks and other computing resources and can deploy and run operatingsystems and applications).

The platform may comprise co-located hardware and software resources, orresources that are physically, logically, virtually and/orgeographically distinct. Communication networks used to communicate toand from the platform services may be packet-based, non-packet based,and secure or non-secure, or some combination thereof.

More generally, the techniques described herein are provided using a setof one or more computing-related entities (systems, machines, processes,programs, libraries, functions, or the like) that together facilitate orprovide the described functionality described above. In a typicalimplementation, a representative machine on which the software executescomprises commodity hardware, an operating system, an applicationruntime environment, and a set of applications or processes andassociated data, that provide the functionality of a given system orsubsystem. As described, the functionality may be implemented in astandalone machine, or across a distributed set of machines.

Typically, but without limitation, a client device is a mobile device,such as a smartphone, tablet, or wearable computing device. Such adevice comprises a CPU (central processing unit), computer memory, suchas RAM, and a drive. The device software includes an operating system(e.g., Google® Android™, or the like), and generic support applicationsand utilities. The device may also include a graphics processing unit(GPU). The mobile device also includes a touch-sensing device orinterface configured to receive input from a user's touch and to sendthis information to the processor. The touch-sensing device typically isa touch screen. The mobile device comprises suitable programming tofacilitate gesture-based control, in a manner that is known in the art.

Generalizing, the mobile device is any wireless client device, e.g., acellphone, pager, a personal digital assistant (PDA, e.g., with GPRSNIC), a mobile computer with a smartphone client, or the like. Othermobile devices in which the technique may be practiced include anyaccess protocol-enabled device (e.g., an Android™-based device, or thelike) that is capable of sending and receiving data in a wireless mannerusing a wireless protocol. Typical wireless protocols are: WiFi,GSM/GPRS, CDMA or WiMax. These protocols implement the ISO/OSI Physicaland Data Link layers (Layers 1 & 2) upon which a traditional networkingstack is built, complete with IP, TCP, SSL/TLS and HTTP.

In a representative embodiment, the mobile device is a cellulartelephone that operates over GPRS (General Packet Radio Service), whichis a data technology for GSM networks. In addition to a conventionalvoice communication, a given mobile device can communicate with anothersuch device via many different types of message transfer techniques,including SMS (short message service), enhanced SMS (EMS), multimediamessage (MMS), email, WAP, paging, or other known or later-developedwireless data formats. Generalizing, a mobile device as used herein is a3G- (or next generation) compliant device that includes a subscriberidentity module (SIM), which is a smart card that carriessubscriber-specific information, mobile equipment (e.g., radio andassociated signal processing devices), a man-machine interface (MMI),and one or more interfaces to external devices (e.g., computers, PDAs,and the like). The techniques disclosed herein are not limited for usewith a mobile device that uses a particular access protocol. The mobiledevice typically also has support for wireless local area network (WLAN)technologies, such as Wi-Fi. WLAN is based on IEEE 802.11 standards.

The underlying network transport may be any communication mediumincluding, without limitation, cellular, wireless, Wi-Fi, small cell(e.g., Femto), and combinations thereof.

The techniques and technologies described herein may be implemented inassociation with a cross-platform SDK for customized development onconnected devices including Android, iOS, Windows, Mac, Linux and ioT.

When the techniques herein are implemented in a mobile device client,preferably the mobile device executes a trusted execution environment(TEE) having a trusted user interface that runs entirely within the TEE.Screen and keyboard input (to the trusted UI) is then isolated from theapps that use the primary device operating system (OS). In such anarrangement typically the primary OS and TEE have independent CPUs,memory and storage, and communications to and from the TEE is done viacommunications channels. In this example, the application (mobile deviceapp) that implements the techniques of this disclosure (e.g., DHTinteraction, virtual circuit building, secure communications, etc.)utilizes tamper-resistant, hardware-level encryption and non-clonablekey generation from the TEE.

An endpoint that implements the techniques of this disclosure mayoperate without the use of personally identifiable information (PII).Depending on implementation, a device provisioned with theabove-described PSP technologies may interoperate with distributed anddecentralized (e.g., blockchain) technologies to provide messaging withrobust privacy control.

Each above-described process preferably is implemented in computersoftware as a set of program instructions executable in one or moreprocessors, as a special-purpose machine.

Representative machines on which the subject matter herein is providedmay be Intel Pentium-based computers running a Linux or Linux-variantoperating system and one or more applications to carry out the describedfunctionality. One or more of the processes described above areimplemented as computer programs, namely, as a set of computerinstructions, for performing the functionality described.

While the above describes a particular order of operations performed bycertain embodiments of the invention, it should be understood that suchorder is exemplary, as alternative embodiments may perform theoperations in a different order, combine certain operations, overlapcertain operations, or the like. References in the specification to agiven embodiment indicate that the embodiment described may include aparticular feature, structure, or characteristic, but every embodimentmay not necessarily include the particular feature, structure, orcharacteristic.

While the disclosed subject matter has been described in the context ofa method or process, the subject matter also relates to apparatus forperforming the operations herein. This apparatus may be a particularmachine that is specially constructed for the required purposes, or itmay comprise a computer otherwise selectively activated or reconfiguredby a computer program stored in the computer. Such a computer programmay be stored in a computer readable storage medium, such as, but is notlimited to, any type of disk including an optical disk, a CD-ROM, and amagnetic-optical disk, a read-only memory (ROM), a random access memory(RAM), a magnetic or optical card, or any type of media suitable forstoring electronic instructions, and each coupled to a computer systembus.

A given implementation of the computing platform is software thatexecutes on a hardware platform running an operating system such asLinux. A machine implementing the techniques herein comprises a hardwareprocessor, and non-transitory computer memory holding computer programinstructions that are executed by the processor to perform theabove-described methods.

The functionality may be implemented with other application layerprotocols besides HTTP/HTTPS, or any other protocol having similaroperating characteristics.

There is no limitation on the type of computing entity that mayimplement the client-side or server-side of the connection. Anycomputing entity (system, machine, device, program, process, utility, orthe like) may act as the client or the server.

While given components of the system have been described separately, oneof ordinary skill will appreciate that some of the functions may becombined or shared in given instructions, program sequences, codeportions, and the like. Any application or functionality describedherein may be implemented as native code, by providing hooks intoanother application, by facilitating use of the mechanism as a plug-in,by linking to the mechanism, and the like.

The platform functionality may be co-located or various parts/componentsmay be separately and run as distinct functions, perhaps in one or morelocations (over a distributed network).

Each above-described process preferably is implemented in computersoftware as a set of program instructions executable in one or moreprocessors, as a special-purpose machine.

The techniques herein generally provide for the above-describedimprovements to a technology or technical field, as well as the specifictechnological improvements to various fields including securecommunications and networking, all as described above.

What is claimed is as follows:
 1. A method of secure communicationoperative at a first endpoint in association with a network of nodesconfigured as a mesh, wherein a node is a computing entity, and at leastsome of the nodes in the network are configured with a discoveryservice, comprising: receiving from the discovery service a list ofnodes in the network; responsive to receipt of the list of nodes,establishing a virtual circuit to a gateway node identified from thelist and requesting that the gateway node establish a connection to aprotected network distinct from the network of nodes and to which thegateway node is coupled; and responsive to receipt from the gateway nodeof given information, the given information confirming that the gatewaynode has established a connection to the protected network,communicating information to an entity in the protected network via thevirtual circuit and the gateway node.
 2. The method as described inclaim 1 wherein the given information also confirms that a userassociated with the first endpoint has an authorization to connect tothe protected network.
 3. The method as described in claim 1 wherein theprotected network is a virtual private network (VPN).
 4. The method asdescribed in claim 1 wherein the virtual circuit has at least three (3)node hops comprising first, second and third nodes, and wherein thesecond node only sees the first and third nodes but not the firstendpoint or the gateway node.
 5. A method of secure communicationoperative at a first endpoint in association with a network of nodesconfigured as a mesh, wherein a node is a computing entity, and whereinindividual endpoints announce their presence on the network anonymouslyby registering presence records in a data structure shared across thenodes, comprising: establishing a virtual circuit to first node to lookup a second endpoint presence record, and building a second virtualcircuit to a second node; building a third virtual circuit to a thirdnode identified in the second endpoint presence record to request aconnection between the first endpoint and the second endpoint via thesecond node; communicating with the second endpoint in response to thesecond endpoint accepting the connection request and establishing aseparate virtual circuit from the second endpoint to the second node. 6.A method of secure communication operative at a first endpoint inassociation with a network of nodes configured as a mesh, wherein a nodeis a computing entity, and wherein individual endpoints announce theirpresence on the network anonymously by registering presence records in adata structure shared across a first subset of nodes, the nodes in thefirst subset being onion nodes, comprising: receiving from a discoveryservice a list of nodes in the network, the list of nodes having beenagreed upon via consensus by a second subset of nodes, the nodes in thesecond subset being discovery nodes; responsive to receipt of the list,building a first virtual circuit to a node designated in the list andissuing a connection request to a second endpoint; building a secondvirtual circuit to a rendezvous node; and communicating with the secondendpoint in response to the second endpoint accepting the connectionrequest and establishing a separate virtual circuit from the secondendpoint to the rendezvous node.